Oct 94 Tips
Volume Number: 10
Issue Number: 10
Column Tag: Tips &Tidbits
Related Info: Color Quickdraw
Tips &Tidbits 
By Scott T Boyd, Editor
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
Tip Of The Month
Faster Color
RGBForeColor and RGBBackColor can take a surprising amount of time, e specially
if your main drawing loop calls both routines before most drawing operations. Even if
you call RGBForeColor with the color that’s currently foremost, it still recalculates
the best possible foreground color! By remembering the results of RGBForeColor and
RGBBackColor, you can significantly increase your drawing speed; this example
program shows a drawing speed increase of 20%!
The program is written to be pasted into a brand new Think C Project; no
MacTraps library is required here. It dumps you into MacsBug at the end with location
$40 holding the unoptimized time and $44 holding the optimized time. You can use
locations $40 through $5B, inclusive, for debugging purposes.
/* 1 */
#include
#include
#include
#include
void main(void) {
CWindowRecord cwr;
WindowPtr wp;
Rect bounds = {100, 50, 100 + 256, 50 + 100};
RGBColor theColor;
unsigned short i, lp;
unsigned short start, stop, inc;
long startT, stopT;
long ColorIndex[1000];
short optimized;
InitGraf( NewPtr(2000) + 1000);
InitCursor();
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(0);
wp =
NewCWindow(&cwr,&bounds,"\pFill",TRUE,zoomDocProc,0,TRUE,237);
SetPort(wp);
OffsetRect(&bounds, -bounds.left, -bounds.top);
for (optimized = 0; optimized <= 1; optimized++) {
startT = TickCount();
if (optimized) {
for (i = 0; i < 256 * 255; i += 256) {
theColor.red = i;
theColor.green = i;
theColor.blue = i;
RGBForeColor(&theColor);
ColorIndex[i >> 8] = cwr.port.fgColor;
}
}
PenPat((Pattern *)"\xF0\xF0\xF0\xF0\xF0\xF0\xF0\xF0");
for (lp = 0; lp < 99; lp++) {
MoveTo(0, 0);
if (lp & 1) {
start = 0;
inc = 256;
stop = 256 * 255;
} else {
stop = 0;
start = 256 * 255;
inc = -256;
}
for (i = start; i != stop; i += inc) {
if (!optimized) {
theColor.red = theColor.green
= theColor.blue
= i;
RGBForeColor(&theColor);
theColor.red = theColor.green
= theColor.blue
= 65536 - 256 - i;
RGBBackColor(&theColor);
} else {
cwr.port.rgbFgColor.red
= cwr.port.rgbFgColor.green
= cwr.port.rgbFgColor.blue
= i;
cwr.port.fgColor =
ColorIndex[cwr.port.rgbFgColor.red >> 8];
cwr.port.rgbBkColor.red
= cwr.port.rgbBkColor.green
= cwr.port.rgbBkColor.blue
= 65536 - 256 - i;
cwr.port.bkColor =
ColorIndex[cwr.port.rgbBkColor.red >> 8];
}
Line(100, 0);
Move(-100, 1);
}
}
stopT = TickCount();
if (!optimized) {
*(long *)0x40 = stopT - startT;
} else {
*(long *)0x44 = stopT - startT;
}
}
DebugStr("\p;dm 40");
CloseWindow(wp);
}
- Jörg ‘jbx’ Brown
San Francisco, CA
Got a developer tip you’ve been keeping to yourself but really need to share?
Think you have a better trick up your sleeve? Send us your tips and tricks, e specially
programming-related tips, but don’t hold back if you’ve got programmer’s user tips.
We want your tips! We pay $25 for every tip used, and $50 for Tip of the Month.
You can take your award in orders or subscriptions if you prefer.
Make sure code compiles, and send tips by e-mail. See page two for our
addresses.
Not Such A Drag After All
The drag manager is really cool and can make apps a lot more intuitive, but it’s a
pain to debug since process switches are disabled while drags occur. Since both Think
C’s and Metrowerks’ debugger require these, you cannot use them. Never fear! You
can use The Debugger!
While we’re on the subject, here’s a gotcha for you. Watch out for a bug that
causes deadlock if you call WaitNextevent from a drag receive handler.
- Rod Magnuson,
Cupertino, CA
Going Faster with Symantec TPM
Symantec C++, both versions 6.0 and 7.0, do not have the compilers as part of
Think Project Manager. Instead, they are kept as quasi-standalone applications inside
the Translators folder (located in the Symantec C++ folder). This goes for the C, C++,
and rez compilers, as well as the .o converter. When the user tells Think Project
Manager to compile a file, TPM looks at the file’s extension (such as .cp for a C++
file), and launches the appropriate compiler (or translator, as Symantec calls them).
This is documented in the Symantec manuals.
What isn’t documented, however, is the process by which TPM launches the
translators. As it is shipped from the factory, when TPM is launched, it turns around
and launches the C++ translator and keeps it in memory. The C translator is left on the
disk, and called when necessary. This works great if you do most of your work in C++.
But if you’re like me, and work mostly in C, this slows down the compilation process
because every time a C file is to be compiled, the C translator must launched and loaded
into memory, while the C++ translator sits there in memory with nothing to do.
What’s a C user to do? Simply modify the C and C++ translators to work the way
you want them to. Using ResEdit (or resource editor of your choice), open ‘INFO’
resource number 0 in the translator named Think C (Symantec graciously includes a
ResEdit template for this). Change the setting of Memory Resident Translator? from 0
to 1. Close and save your changes. Voila! The C translator will now be loaded and kept in
memory by TPM when it is launched. In one simple step, C compiles are now speeded
up. The more files that are being compiled, the greater the speed increase. For
instance, a one-file compile is not speeded up much, but if you’re working with large
projects, the speed increase can be significant.
If you want to free up some memory, you can also modify the C++ translator
(named Symantec C++) to not be memory resident.
- Chris Hawk
San Francisco, CA
Referenced by (2):